A mobile or cellular telephone system is an example of a communication system that is capable of transmitting and receiving data between end user equipment or applications and network equipment. Transmitted and received data may be in the form of data packets. Transmitted data packets may be in a variety of formats and include a variety of different types of data, including voice data, binary data, video data, and the like.
In a communication system, such as a mobile or cellular telephone communication system, various methods are used to establish the rate of communication or bitrate at which data packets are transferred between a user's mobile device, such as a mobile telephone, and the rest of the system. For example, if Adaptive MultiRate (AMR) or Adaptive MultiRate—Wideband (AMR-WB) transmission is used, at call set-up a mode set is negotiated through a Session Description Protocol (SDP). The Session Description Protocol parameter “mode-set” takes a value that represents a subset of bitrates that can be used during a call. The value is selected from the set {0, . . . , 7} for Adaptive MultiRate transmissions and from the set {0, . . . , 8} for Adaptive Multi Rate—Wideband transmissions. The value to be used may be selected, for example, based on detected signal strength between the mobile device and the rest of the network at the time of call set-up. The mode-set value represents a subset of bitrates that can be used during the call. When a sender encodes speech it must use one of the bitrates in the mode set. The mode used to encode is then indicated to the receiver in a Codec Mode Indication (CMI) field of the Real-time Transport Protocol payload.
For Long Term Evolution (LTE), the relevant specification in terms of codec rate adaptation is 3GPP TS 26.114, which specifies the Multimedia Telephony Services over IP Multimedia Subsystem (MTSI). Included in this specification are several means of adaptation. For example, bit rate, number of frames per packet, and amount of redundant frames per packet, may all be adapted according to requests from the receiver of the encoded media. These requests are generally included in the RTP Control Protocol Application Defined (RTCP APP) packets.
Problems arise in a communication system when the demands on the network system to timely process data packets for transmission through the system exceeds network capacity. In such situations, the network is said to be experiencing congestion. A typical response to such congestion is for the network simply to drop packets received from or to be transmitted to a user application and that cannot be processed by the network in a timely manner.
Explicit Congestion Notification (ECN) is a method for the network to indicate to user applications that the network is experiencing congestion. In response to receiving such a notification, a user application can reduce its sending rate in order to avoid packets being dropped. For example, Explicit Congestion Notification may be implemented by marking two bits in the Internet Protocol (IP) header of a packet as ‘11’, indicating that congestion is being experienced by a network element processing the packet. Via a feedback mechanism, the sender of the packet is notified of the congestion and can then reduce its sending rate.
Until recently, it has not been specified how to apply Explicit Congestion Notification to User Datagram Protocol (UDP) traffic. The User Datagram Protocol itself does not contain a feedback mechanism. However, most real-time applications, such as voice, video, real-time text, and the like, use Real-time Transport Protocol (RTP) over User Datagram Protocol, which does have a feedback mechanism, namely RTP Control Protocol (RTCP). It has been proposed to use explicit congestion notification with Real-time Transport Protocol. In this proposal, the receiver of Internet Protocol packets that are marked “congestion experienced” communicates this information to the sender through the RTP Control Protocol feedback packets. The sender can then reduce its bitrate in order to reduce congestion. For Adaptive Multi Rate (AMR) or Adaptive Multi Rate—Wideband (AMR-WB) transmissions, the sender can change its transmission mode to reduce congestion.
As an alternative, the receiver of packets marked for congestion experienced may use the Codec Mode Request (CMR) field in the Real-time Transport Protocol payload to request that the sender reduce its bitrate. This has the advantage that additional RTP Control Protocol traffic is not created, when the network is already congested, in order to communicate which packets were marked for congestion experienced to the sender. It has the disadvantage that it cannot be used to control the bitrates when data packet flow is unidirectional. For codecs that do not have a Codec Mode Request field in the Real-time Transport Protocol payload and for other media types, it is possible that a Temporary Maximum Media Stream Bit Rate Request (TMMBR) may be used to request the sender to reduce its bitrate.
Therefore, it would be advantageous to have a method and apparatus that takes into account at least some of the issues discussed above, as well as possibly other issues.